A standard way to communicate between two processes A and B (running on the same machine or running on different machines) is to send a message. Often, for example, it is desirable to enable process A to send a message to process B asking process B to execute code on behalf of process A. Typically, process A must have knowledge of a port or contact point for process B in order to do this.
One way to enable process A to call process B is via a remote procedure call (RPC). A remote procedure call enables a process on one computer to cause code to be executed in another process on the same or on a different computer, without requiring explicit code to be written by a developer or programmer to perform that particular call. An RPC is initiated by the caller process (client) sending a request message to a remote system or second process (server) to execute a certain procedure using supplied arguments. A result message is returned to the caller. For example, in a remote procedure call, a function call may be made by process A, in which the name of the procedure that process B is to execute on behalf of process A and a set of parameters for the procedure, are specified. Process B executes the code and returns a message to process A. When the code in question is written using principles of object-oriented programming, RPC is sometimes referred to as remote invocation or remote method invocation.
A remote procedure call typically follows a particular protocol (another way of saying this is “it uses a particular interface”) so that potentially unrelated processes can communicate. The protocol or interface define the methods and the values which the processes agree upon in order to cooperate.
The procedure of transforming the function call into a message is called marshalling. Marshalling may include gathering data from one or more applications or non-contiguous sources in computer storage, putting the data pieces into a message buffer, and organizing or converting the data into a format that is prescribed for a particular receiver or programming interface. Marshalling typically converts what the code in process A sees as a function call into a message to be sent to process B. The message typically includes the name of the function and a set of parameters, coded in a way that process B understands. Process B receives the message and has to transform the message into a call to process B's internal function. The process of converting a message into a function call is called unmarshalling. The piece of code that performs marshalling in process A is called a proxy and typically resides in the client process. The corresponding piece of code on the server side that performs unmarshalling is called a stub.
Within the context of object oriented programming, process A and process B can be viewed as objects encapsulating data and functions. Some well-known technologies that take this approach are Sun Microsystem's JAVA and Microsoft's COM and DCOM. That is, process B may be viewed as a container for one or multiple objects, whose methods are the functions invoked by process A. In object oriented systems, therefore, process A invokes a method of a particular object of process B instead of invoking a function in process B. To do this, process A must have some way of identifying the object in process B that process A wishes to invoke.
The data stored in process A which enables process A to identify the object of process B is known as a reference to the object. The reference stores information concerning how to locate the object: that is, the reference must be sufficient to identify the process and within the process to identify the object whose method is to be invoked.
It is often desirable to share resources within a computer system. As described above, one convenient way to share resources is through an interface that provides programmatic access to the shared resource. The program responsible for the resource is called the server and employs a stub program to handle access requests for the particular type of resource being shared. The program seeking access is called the client and employs a proxy program to make the request for the particular type of resource being requested
When lengthy pieces of information are exchanged between processes on the same or on different computers, or are stored, it is often helpful to compress these lengthy pieces of information from an arbitrary length into a smaller fixed-size integer identifier. One way to do so is to assign a sequential small integer to each piece of information as it is encountered. The process of doing so is often referred to as set enumeration.
For example, suppose descriptions of types of data being exchanged (such as interface type name) are passed in messages. To assign a sequential, small integer to be used as an interface type identifier instead of using the lengthy interface type name, a sequential integer could be assigned to each interface type as it is encountered, either as a list of interface types are generated or as interface types are accessed during execution. In other words, a first interface type name encountered or accessed in a particular execution may be assigned the type identifier “1”, the next one “2” and so on. When the interface type names are assigned identifiers using the same scheme (for example, by the same agent or module within the same machine in the same execution), always identifying a particular interface type with the same small number is not particularly challenging. When, however, the same interface type is given different identifiers because the interface type identifiers are assigned by different agents within different machines, using different access sequences in different executions, matching up the interface type identifiers becomes a non-trivial exercise. It would be helpful if there were an efficient mechanism to solve this problem.